The Ultimate Mac Cracking Guide DISCLAMER: I, ProZaq, take NO RESPONSIBILITY for any damage done to your or anyone else’s computer as a result of following the instructions in this file. I take further NO RESPONSIBILITY for anyone using this file for illegal purposes. If YOU do anything illegal it’s YOUR SHIT! I intend this file for educational purpouses only. I therefore strongly recomend you registering all sharewares, to keep shareware developers alive, and so that we have a chance against the hughe multi-million-dollar software developing companies! If you decide to use the methods described here for illegal things, don’t blame me if you get caught! --==< Intro >==-- This file is the first part for the complete guide to cracking programs for the Mac. It is planned that when this file is complete it will give a full look at all the ways of cracking programs that I can come up with. There are two references that should be read before reading this article*: “List of Commands” and “Beginner's Guide to Assembly”. The former contains a list of the most common 68K Mac assembly commands and the later is a guide to how assembly language works. Before you go on reading, read “Beginner's Guide to Assembly”, as I asume that anyone reading this already knows assembly! Also, some of you might find this file a bit lenghty and wordy. But remember that I try to describe the methods of cracking thoroughly and in as much detail as possible! *Weasel's note: “Beginner's Guide to Assembly” was included in HackAddict 5. “List of Commands” is located in “Appendix A: List of Commands” in this issue. --==< Table of Contents >==-- I. Software you will need II. How to Use Macsbug III. Exploiting Dialogs IV. Using A-traps With Dialogs V. How to Crack (in theory) VI. How to Crack (in real life) VII. End of Part 1 --==< Software you will need >==-- So what will you need to be a cracker? Well you will need MacsBug, and Super ResEdit (ResEdit with a code editor). MacsBug is a debugger. It was created to allow programers to follow their code through and to find errors and incompabilities. Super ResEdit differs from ResEdit in that it allows you to view the “CODE” resource as assembly commands (instead of a bunch of hex numbers). MacsBug is included with this archive. Look for Super ResEdit at www.weasel.org (when it is up) or the HackAddict Hotline Site. --==< How to Use Macsbug >==-- You install MacsBug simply by throwing it into the system folder, and restarting your machine. You activate it by pressing the “command” and “power-key” (the one towards the top of your keyboard marked with the head of an arrow pointing to the left) buttons. This should have “dropped” you into MacsBug. You will notice that you are in MacBugs ‘cause your desktop is replaced with a with a bunch of numbers on a white background. Well, going from the top left side, under “SP” is the current position of the stack pointer, underneath the position of the SP are the values contained in the SP. Under those numbers is the name of the application that is currently the foremost active. Under that is the status of the Status Register (he he), followed by the info held in the 8 data registers, and the 8 address registers. To the right of the address registers is a horizontal line going across the screen. Under that are about 4 lines of text. The topmost line discribes where in the application’s code the processor was halted. Under that line are 3 other lines with assembly commands. These are the three commands in line to be executed. To the right of them (in the right bottom corner) are the hexadecimal values of the assembly commands. If the topmost assembly command is a conditional such as BEQ then “Will/ Will not branch” will appear between the command and it’s hex value. Underneath the “Will/ Will not branch” is a hex number. “Will branch” means that the given condition was satisfied and that the program will branch to the address defined by the number underneath the “Will/ Will not branch”. If it says “Will not branch” then the number will appear underneath it too. This means that the program will not branch, but continue on with the next command in line. But would it have branched it would have branched to the memory address represented by the hex number. This is a very important concept and it gets important later on! Above this section is a large empty space. This gets filled up with the results of the commands you give to MacsBug. Your commands get written under the three assembly commands. What happens when you drop into MacsBug is that your processor stops executing commands, and you can go through a code step by step, command by command, follwoing through exactly what the program does. So how do you do it? Type “t” followed by a return. This causes the processor to execute the next assembly command in line. The assembly command that was executed appears now in the middle blank section of your screen, and a new assembly command appears under the two old ones. --==< Basic MacsBug Commands >==-- - t : traces over the next command in line. If it is used on a JSR command it jumps over the the subroutine. (It executes the whole soubroutine, without allowing you to see what happened) - s : does the same thing as “t” except it “steps into” a subroutine. For example if you are not interested in what happens in an subroutine you should type “t”. This causes the processor to continue untill it reaches a RTS command, and only then give the controll back to you. If you on the other hand want to see what happens in that subroutine, you should type “s” to step into it and follow through the code from there. - es : this forces the current application to quit (not always). - rs : restarts your computer (sometimes it doesn work and you have to do it the old fashioned way: apple-control-powerkey) - rb : reboots your computer (boots up the different external devices at startup). This is slower then the “rb” command - dm [address] : displays what is in the memory at a given address. For example the command “dm a6” shows you what is held in the address pointed to by address register 6. If you type “dm abcd” it shows you what is held in the memory at location “abcd”. - db [address] : displays byte from address - dw [address] : displays word from address - dl [address] : displays long from address - il : dissambles the codes. Used if you for example want to see what happens after a branch code. - atb [a-trap name] : MacsBug activates every time that a-trap is being called. - atc : clears a-traps - f address expr ‘string’ : this is the find command. “address” reffers to the starting point of the serch “expr” is how many bytes it should serch and “ ’string” is what you’re looking for! Observe the semi quotation mark before the string! You need to use that! You can find out more about commands for MacsBug by typing “help” Super ResEdit is used to a large extent to change the assembly commands and resources in an application. More about it when we need to use it! --==< Exploiting Dialogs >==-- All right! Let’s get started! The first approach to cracking a program is by exploiting the serial number dialog box. Usually when a software asks you to enter a password or serial number, it puts up a dialog box. By dropping into MacsBug you will be able to follow through the code, see what’s going on, and change the code to fit your needs! The trick with droping into MacsBug is to drop in at the right time. If you don’t then you’ll probably spend hours following through thousands of commands only to find yourself completely lost! So what is “the right time”? The right time is dropping into MacsBug right when it starts the routine which checks the serial number. With other words, dropping in at the series of commands, written by the software author, that deal with the registration. So how do you do this? This is when a-traps become important. You see, MacsBug has this function which allows you to automaticly enter MacsBug. if an a-trap is about to be executed. This is the: “atb [name of a-trap]” function. For example you can type: atb getnewdialog followed by a return, and every time the processor is about to run a “getnewdialog” a-trap you will automaticly be thrown into MacsBug. Within the Mac OS there are a bunch of a-traps dealing with dialogs. For example a lot of times dialogs use the “ModalDialog” a-trap. So if you want to drop into MacsBug whenever the “modaldialog” trap is called you would drop into MacsBug and give it the following command: “atb modaldialog” (without quotes). Whenever you’re done with a trap, I advise you to give the command “atc” to MacsBug since this turns off the scan for a-traps. OK I feel lame so I’m gonna give you a list of all the a-traps dealing with dialogs (to the best of my knowledge): InitDialogs ErrorSound GetNewDialog CloseDialog DisposeDialog CouldDialog FreeDialog ParamText ModalDialog IsDialogEvent DialogSelect DrawDialog UpdateDialog Alert StopAlert NoteAlert CautionAlert CouldAlert FreeAlert GetDialogItem SetDialogItem HideDialogItem ShowDialogItem SelDialogItemText GetDialogItemText SetDialogItemText FindDialogItem NewColorDialog The truth is that you don’t need to learn all of these, but it might come in handy if you have a list of them all. (The a-traps dealing with alerts refer to alert dialog boxes, ie. ones that only have an OK button on them). --==< Using A-traps With Dialogs >==-- First I will guide you through the cracking of a program that puts up a registration dialog box and asks you to enter your registration name and registration number. The principle behind this is as follows: the program puts up the dialog box, then it lets you enter the registration number (reg#) and your registration name, then it takes your registration name and does a bunch of calculations with it, compares the answere to the reg# you entered, and depending on whether the reg# you entered was right or wrong a conditional branch will occur. Remember what conditionals are? Instructions like: BGE, BNE, BEQ (branch if greater or equal, branch if not equal, branch if equal). So what we want to happen is to drop into MacsBug straight after clicking on the OK button, and then trace through the instructions looking for that conditional which decides wether the reg# we entered was right or wrong. And once we found it we want to change it so that no matter what we type as a reg# it will always say that the number we entered is correct! The most basic approach to this is through the “ModalDialog” a-trap. Modal dialogs are dialog boxes that are fixed on the screen and only dissapear after you clicked one of the buttons. The only thing you have to know about modal dialog boxes are that information is usually collected from them after the user (cracker) presses the OK button and that the information you typed into the text-fields of the dialog box will be pushed into the memory with the “GetDialogItemText” a-trap! --==< How to Crack (in theory) >==-- So how would I set out to crack the program in real life? I would start off by picking a unique number (that I can easily recognize) such as 123456789. Then I would enter ANY name as the registration name. Then I would type 12345678 (without the nine) as the reg#. Then I would drop into MacsBug and issue the modaldialog trap command (atb modaldialog). Then I would go back to the application with the “g” command. Then I would type the number nine. This should drop me into MacsBug again. The next command is the trace (“t”) command, which drops me back into the application. Now I would click on the OK button, and find myself in MacsBug. again. And presto, I’m in the right place. After this it is just a matter of steping and tracing through the code tyring to figure out where the conditional branch I want to change is! “OK, I think I found the conditional I was looking for...What do I do now?” Easy! If the conditional does not branch but you want it to branch, type “pc=address” where address represents the hex number under the place where it says “Will branch” or “Will not branch”. This should have brought you to a whole new place in the code. After giving the “g” command, the “thank you for registering” dialog should appear if you changed the right conditional! However, sometimes the code will branch when you don’t want it to. So if you wanted to jump over the current instruction (since not giving the pc a command is like jumping over a command) you would give MacsBug the command “pc=pc+n”, where n is the length om the assembly instruction. How do you determine n? In MacsBug in the right bottom corner next to the assembly instructions are hexadecimal numbers. These numbers are the equivilents to the assembly commands in hexadecimal form. This way you can determine the commands leangth. Just count how many digits the hex number next to the command is, divide it by two and you have the value of n! So if the number is “AAFE” n would equal 2, and if the number is “AABB 1234” then n would equal 4. Get it? HINTS: 1. The GetDialogItemText a-trap puts the things you entered in the dialog box in address register one. So by checking the value in address register one (give the command “dm a1”) you can decide where the program is collecting the from the dialog, and where it started to mess around with the registration number. 2. Some people would advise you not to stop for ModalDialog a-traps but to do GetDialogItemText or GetDialogItem a-traps straight away. They would argue that this would bring you further into the code. But I don’t like this approach because the GetDialog commands are usually issued from within subroutines of the main code which means that I have no idea of where in the code I am. But with the ModalDialog I always know that I’m at the command after the dialog a-trap. 3. Stepping thorugh the code can become a bitch! I can storongly suggest that you trace through the code at first! Meaning: jump over subroutines, and check which one brings up the dialog saying that the number you entered is invalid. Chances are that the conditional you’re looking for is in that subroutine. So the next time, step through that subroutine and see what the code does! And if that wasn’t the right subroutine go to the one before it! This WILL save you a lot of time! 3.a) NEVER EVER step into an a-trap! You can reckognize a-traps because they have an “_” sign infront of them. 4. Pay attention to what’s going on in the data and address registers! You are following through the code to understand what the program does! If you try the trial and error way, it will probably take you a hell of a long time! So issue the “dm [addres]” command often! So this was the theory, now let’s do the real thing! --==< How to Crack (in real life) >==-- This code is take from a real program. But because of copyright issues I will not name the program I took it from! I will just describe the different steps, and what’s going on! First here is the full code from the ModalDialog trap untill the conditional that I’m looking for: +0009A 00D2E6F6 _ModalDialog ; 00293126 | A991 +0009C 00D2E6F8 MOVE.L -$0004(A6),-(A7) | 2F2E FFFC +000A0 00D2E6FC MOVE.W -$0414(A6),-(A7) | 3F2E FBEC +000A4 00D2E700 PEA -$030A(A6) | 486E FCF6 +000A8 00D2E704 PEA -$0008(A6) | 486E FFF8 +000AC 00D2E708 PEA -$0312(A6) | 486E FCEE +000B0 00D2E70C _GetDialogItem ; 00292E38 | A98D +000B2 00D2E70E CMPI.W #$0001,-$0414(A6) | 0C6E 0001 FBEC +000B8 00D2E714 BNE XXXXXXXXX+001AA ; 00D2E806 | 6600 00F0 +000BC 00D2E718 MOVEQ #$01,D3 | 7601 +000BE 00D2E71A MOVE.L -$0004(A6),-(A7) | 2F2E FFFC +000C2 00D2E71E MOVE.W #$0006,-(A7) | 3F3C 0006 +000C6 00D2E722 PEA -$030A(A6) | 486E FCF6 +000CA 00D2E726 PEA -$0008(A6) | 486E FFF8 +000CE 00D2E72A PEA -$0312(A6) | 486E FCEE +000D2 00D2E72E _GetDialogItem ; 00292E38 | A98D +000D4 00D2E730 MOVE.L -$0008(A6),-(A7) | 2F2E FFF8 +000D8 00D2E734 PEA -$0412(A6) | 486E FBEE +000DC 00D2E738 _GetDialogItemText ; 002929A4 | A990 +000DE 00D2E73A LEA -$0412(A6),A0 | 41EE FBEE +000E2 00D2E73E MOVE.L A0,D3 | 2608 +000E4 00D2E740 MOVEA.L D3,A0 | 2043 +000E6 00D2E742 MOVEQ #$00,D0 | 7000 +000E8 00D2E744 MOVE.B (A0),D0 | 1010 +000EA 00D2E746 ADDQ.L #$1,D0 | 5280 +000EC 00D2E748 MOVEA.L D3,A0 | 2043 +000EE 00D2E74A LEA -$0308(A6),A1 | 43EE FCF8 +000F2 00D2E74E _BlockMove ; 401AD5D8 | A02E +000F4 00D2E750 MOVE.L -$0004(A6),-(A7) | 2F2E FFFC +000F8 00D2E754 MOVE.W #$0008,-(A7) | 3F3C 0008 +000FC 00D2E758 PEA -$030A(A6) | 486E FCF6 +00100 00D2E75C PEA -$0008(A6) | 486E FFF8 +00104 00D2E760 PEA -$0312(A6) | 486E FCEE +00108 00D2E764 _GetDialogItem ; 00292E38 | A98D +0010A 00D2E766 MOVE.L -$0008(A6),-(A7) | 2F2E FFF8 +0010E 00D2E76A PEA -$0412(A6) | 486E FBEE +00112 00D2E76E _GetDialogItemText ; 002929A4 | A990 +00114 00D2E770 LEA -$0412(A6),A0 | 41EE FBEE +00118 00D2E774 MOVE.L A0,D3 | 2608 +0011A 00D2E776 MOVEA.L D3,A0 | 2043 +0011C 00D2E778 MOVEQ #$00,D0 | 7000 +0011E 00D2E77A MOVE.B (A0),D0 | 1010 +00120 00D2E77C ADDQ.L #$1,D0 | 5280 +00122 00D2E77E MOVEA.L D3,A0 | 2043 +00124 00D2E780 LEA -$0108(A6),A1 | 43EE FEF8 +00128 00D2E784 _BlockMove ; 401AD5D8 | A02E +0012A 00D2E786 SUBQ.W #$2,A7 | 554F +0012C 00D2E788 PEA -$0308(A6) | 486E FCF8 +00130 00D2E78C PEA -$0108(A6) | 486E FEF8 +00134 00D2E790 JSR xxxxxxxxxxx | 4EB9 00D2 CDD8 +0013A 00D2E796 MOVE.B (A7)+,D0 | 101F +0013C 00D2E798 BEQ.S XXXXXXXXX+00142 ; 00D2E79E | 6704 Wow! Does that firghten you? Well it shouldn’t! If you follow the hints I gave you, you should not even have to spend too much time finding the right conditional. OK here’s a summary of the most important commands from the above exert: + 000B0 GetDialogItem + 000B8 BNE XXXXXXXX+001AA Will Not Branch + 000D2 GetDialogItem + 000DC GetDialogItemText + 000F2 BlockMove + 00108 GetDialogItem + 00112 GetDialogItemText + 00128 BlockMove + 00134 JSR XXXXXX + 0013C BEQ XXXXXXX+00142 Will Branch Ok, so notice the things that I selected to be important! These are the branch commands and the GetDialog a-traps, and the subroutines! An important part of cracking is to reckognize the things you are looking for! And the things you don’t want to spend time on analyzing! Offcourse the first time you’re cracking something you will most likely go through each and every command. But as you get better and better you learn to spot the important ones! In the summary the first GetDialogItem trap and the conditional that follows it are unimportant! I reckognized this by branching onto the address given. Since the program froze on me, that was not the conditional I was looking for! The a-trap at offsett DC is the one that puts the name I put as registration name into address register one and the BlockMove probably stores my name somewhere in the memory. At this point I know that the program is still just collecting the data from the dialog. The next couple of a-traps store the number I entered as a reg# in the memory. At this point I know that now the program has all the data it needs and will soon start checking the reg# I entered. And as I expected soon after the BlockMove there is a subroutine. From common sense I guessed that this subroutine is where the program compares my reg# to the real one. So I trace over it. And at 13C is a conditional. It will branch. So I let it branch and see what happens. I find out that all the things I don’t want to happen, occur. Therefore, I repeat the procedure and come back to this instruction again. But this time I jump over the command. How do I do it? I give MacsBug the command “pc=pc+2” since the hex value of the command is 6704, which is four digits long. This jumps over the command. I issue the command “g”, and voila: the “thank you or registering” dialog appears! As another example, if the conditional above was not BEQ but BNQ, then the program would not have branched. Let’s say that I wanted it to branch. How do I do it? Easy I just give the command “pc=00D2E79E” since 00D2E79E is the address that appeared under where it says “will not branch”. --==< End of Part 1 >==-- Well folks, that concludes the first part of this file! Do not think that you’re actually done with cracking the program! But I felt like keeping you in suspense so I will wait ‘till the next issue of HackAddict to let you know how to actally change the code with ResEdit. In Part 2 of The Ultimate Mac Cracking Guide I will also discribe several more ways of cracking programs that can not be cracked with the ModalDialog trap method! Part 2 will hopefully be published in the next issue of HackAddict. So until then you’ll have plenty of time for experimenting and getting experienced! - ProZaq